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Description 
Proc^e et dispositif pour I'interfagage graphique 

[001] La pr6seiite invention concane un proc6d6 ainsi qu'un dispositif pour 1' intecfa^age 
gr^hique entre un utilisateur et un sy steme infonnadque. 

[002] Elle trouvera en particulier son application dans le domaine de la realisation 

d' interface graphique pour utilisateur, notaniment dans le domaine des systemes de t6^ 
servadon par or^nateur. 

[003] D'une fagon g6n6rale, les interfaces utilisateurs ont connu une grande Evolution 

depuis rimportant succes des r6seaux de large extension et en particulier de I'lhtemet. 

[004] Les solutions d'interfa^age graphique dans le cadre d'lhtemet ont pennis 
d'iniportantes Economies en maddre de d6veloppement 

[005] dependant, pour des applications complexes, telles que des applications profes- 

sionnelles de systemes de reservation par ordinateur, les interfaces d'utilisatears basSes 
snr ces techniques n6cessitent le transfert de gcandes pages volmnineuses dans un 
format de balisage du type HTML (pour Hyper Text Mark-up Language). 

[006] Des inconv6nients li^s ^ ce type de transmission de pages integrales form6es 

uniquement dans la partie serveur et transmises au navigateur du poste client posent 
plusieuis probl&mes. En particulier, la partie client de I'interfoce d'utUisation pr^sente 
d'importantes limitations structurelles, li^es au langage HTML. En outre, con^ite-tenu 
du volume des transferts a opdrer entre le serveur et le poste client, Toccupation du 
reseau de transmission est forte, ce qui implique un temps de reponse 61ev6 pom: les 
clients disposants d'une connexion a faible debit 

[007] Ce type de construction de pages HTML ressort du document US-A-20021 164S5. 

[008] Suivant des techniques un pen difi&entes, des feoilles de style (stylesheets) sont 
stock^es localement pour etre rfutilisees, en fusion avec des dossiers dynamiques. 
Cependant, ces femlles de style sont pred6finies et leurs caracteristiques sont fix6es d6- 
finitivement EUes n'offrent aucune souplesse d' utilisation. Par exen^)le, s'il convient 
de cr^er une page avec une feuille de style diff&cant, mSme de fagon minime, de la 
feuille pr6sente dans le cache local, la feuille locale n*est pas exploitable et il faut 
obtenir une nouvelle feuille de s(yle compile depuis le serveur. 

[009] n existe un besoin concemant des interfaces utilisateur disposant des atouts de 

richesse, de flexibilit6 et de performance des traitements op6r6s dans la partie serveur 
tout en assurant une reduction de Toccupation du reseau pour foumir Taftichage au 
client 

[010] La pr^sente invention s'inscrit dans le cadre de cette optimisation et pennet de 

r^uire d'une part le temps de calcul sur le serveur et d' autre part le trafic sur le reseau 
entre le serveur et le client, ce qui permet de diminuer le temps de rgponse global de . 
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rs^plicadon. En outre, le dispositif de rinvention conserve une grande flexibility car 
la partie serveur continue de contr61er le traitement des doim^s h afficher. Le 
dispositif permet figalement de modifier et de creer les modules de visualisation 
gr^bique a affich^ pour Tulilisateiir ainsi que de foumir des instructions en ce qui 
conceme I'affichage au poste client 
[01 1] Plus pr6cis6nient, I'inv^tion a Favantage de foumir aux moyens de visualisation 
des informations fusionnees entre deux sources de donnees. En effet, d'une part, le 
dispositif de I'invention g6n^re des objets statiques conserve localement au niveau du 
poste client et permettant une disponibilit6 locale de multiples objets graphiques 
utilises pour TaSichage. 
[012] D'autre part, les donn^ dynamiques conespondant h la demande du client sont 
g^n^rdes aprSs traitement dans la partie serveur et transmises au poste client. Une 
fusion des donnees dynamiques et statiques est ensuite op6T6e pour produiie la vi- 
sualisation en particulier sous forme de pages au format HTML en utilisant une ap- 
plication de navigation. 
[013] En irapl6mentant un 6quipement sp6cifique au niveau du poste client, on pent 
g6nerer localement le module de visualisation k exploiter pour Taffichage. Cela est 
op6r6 par T association de diff^rents elements de constructions du modele qui secont 
d6taiU6s plus loin dans la description. 
[014] n s'ensuit que les donnees de construction des modeles de visualisation ne 

tiansitent plus par le r^seau. En outre, le systdme est ais6ment personnalisable selon les 
exigences locales du poste client (objets graphiques sp6cifiques, regies logiques par- 
ticuli^es h appliquer, donn6es locales particuliferes k employer. . 
[015] Cette personnalisation potentielle du poste client n'affecte pas ses constituants 

d'origine et en paiticulier le navigateur : on pent en effet g6n6rer une page au format 
HTML directement exploitable par le navigateur. 
[016J On notera 6galement que, les modules de visualisation £tant cr66s k partir d'objets 

de faibles tailles, leur mise ^ jour ne n6cessite que pen de ressources r&eau. 
[017] On rfiduit ainsi consid6rablement le volume des donn6es k transmettre entre la 
partie serveur et le poste client. C'est ainsi que Ton b^fide de la richesse des 
standards de langage de balisage (tel HTML) tout en diminuant considfiiablement le 
temps de rdponse et les besoins en r^seau. 
[018] D'autres buts et avantages apparaitront au cours de la description qui suit d'un 

mode pi6f(Sr6 de realisation de Tiuvention qui n*est c^endant pas limitatif. 
[019] La pr&ente invention conceme un proc6d6 pour I'interface grapWque entre un 
utilisateur et un systeme informatique dans lequel on effectue les actions suivantes : 

- entrfe d'une demande par rutilisateur au niveau d'un poste cEent, 

- Transmission de la demande vers une paitie s^eur en vue du traitement de la 
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demande et de la g6ii6ration d'une r6ponse, 

- Reception de la r^ponse au niveau du poste client, 

- AfGcbage du r^ultat de la r^ponse pour V udlisateur, 
[020] Selon rinvmdon : 

~ L« poste client revolt une r^ponse coinpienaat des donn^es d*instruction et 
des donn^ h afScher ; 

- Au niveau du poste client, on ex&ute les donnees d'instruction pour la 
construction d'un module de visualisation h exploiter ; 

Au niveau du poste client, on cr£e ledit module de visualisation par as- 
sociation d'616ments de construction disponibles localement, 

- On fusionne les donnees k afficher avec le mod&le de visualisation en vue de 
I'affichage du r^sultat de la fusion. 

[021] Suivant des possibilit6s avantageuses mais non Umitatives : 

- Les ^ments de construction comprennent une interface de descdption des 
objets du module de visualisation* une couche de pi6sentation et des idgles 
logiques h appliquer localement au module de visualisation ; 

- Au niveau du poste client, on associe au module de visualisation cree un 
lessource de langage panni les ressources de langage disponibles localement ; 

- Au niveau du poste client, on pent associer an module de visualisation des 
filtres de personnalisation d'afEtcbage pour modifier le rendu visuel du 
moddle de visualisation par d^feut; 

- Les donnees d'instruction comportent I'indication du type et les 616ments ca- 
ract&istiques de construction de module de visualisation k cr^er ; 

- On met & jour les donn6es disponibles localement au niveau du poste client 
paries itapes suivantes : 

• On g^n^ie, au niveau du serveur, un message de stockage compienant des 
donn6es d'instruction de stockage et les donnees h stocker, 

• On transmet le message de stockage au poste client, 

• Au niveau du poste client, on intetprfete les donn6es d'instruction pour 
ex&mter le stockage et on stocks les donnfes k stocker dans une m&noire 
locale. 

- On effectue raffichage au niveau du poste client par une application de 
navigation, 

- On utilise des donndes k afficher et des 616ments de construction des modules 
de visualisation au format XML 

On traduit le r6sultat de la fusion au format HTML en vue de TafSchage. 

- La r£ponse de la partie serveur coixq>jiend des donnees d'instruction et des 
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donn^ h afKcher ; 

[022] L'invention est aussi relative ^ un dispositif d'interfa^age gr^hique entce un 
utilisateur et un syst^me infoimatique comprenant : 

* Des moyens d' entree d'une demande par rutilisateur an niveau d'lrn poste 
client, 

* Des moyens de conununication entre le poste client et une paitie serveui, 

* Des moyens de traitement dans la partie serveur pour la g^n^ration d'nne 
n^onse, 

* Des moyens d'afGchage du r6sultat de la r^ponse au niveau du poste client 

- n comporte an niveau du poste client un gestionnaiie d'instructions apte k in- 
teipF6ter les donn6es d' instruction pour la constcuction d'un module de vi- 
sualisation h exploiter ; 

- n comporte un moteur d'association au niveau du poste client apte k creer 
ledit modele de visualisation par association d'i36ments de construction ; 

- n con^orte des moyens de stockage des 61^iDents de constmctions au niveau 
du poste client ; 

- n comporte au niveau du poste client des moyens pour fiisionner le modele de 
visualisation et les donn^es k afficher, en vue de Taffichage du r6sultat de la 
fusion. 

[023] AtitreprfiKr^: 

- Les &6msnts de construction comprennent une interface de descnption des 
objets du modele de visualisation^ une couche de presentation et des regies 
logiques h ^pliquer local^ent au module de visualisation ; 

- n comporte un moteur de regies apte a appliquer les rfegles logiques du 
module de visualisation ; 

- XL conqiorte une application de navigation pour I'affichage du r€sultat de la 
fusion au niveau du poste client 

[024] Les dessins ci-joints sont donnas k titre d'exemples et ne sont pas limitatifs de 
l'invention. Us repr^entent seulement un mode de realisation de Tinvention et 
petmettront de la comprendre aisSment 

[02S] La figure 1 est une representation sch^matique du traitement op6F$ actuellement 
entte un client et un serveur lorsqu'une requSte est formulae par un client en utilisant 
une architecture basee sur le systeme Internet et Tusage d'un navigateur du ^e 
Internet Explorer ®. 

[026] La figure 2 pr6sente sch6matiquement le traitement d'une demande par un client 

avec mise en o&uvre de Finvention. 
[027] La figure 3 illustre des blocs d'^^ments constituti£s du dispositif de Tinvention et 

leur communication. 
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[028] La figure 4 montce '6tape de fusion de doim6es r^s6es. 
[029] La figure 5 est un exemple de composant int6gr6 dans les moy^ de visualisation 
du poste client. 

[030] On a repi€sent6 en figure 1 un scenario standard lors de I'utilisation du reseau 

d' extension mondial usuellCTient 6€nomnx6 <c World Wide Web Dans ce cadre, les 
requites de I'utilisateur au niveau de la partie client correspondent h une demande de 
page au format HTML (Hyper Text Mark-up Language) avec les instructions 
suivantes : http get ou http post. 

[031] Une premiere limitation de ce m^canisme est que I'utilisateur doit prgciser la 

fengtre qui va rdaliser Taffichage de la r^ponse et ce avant d'envoyer la requete. Le 
serveiu: ne peut done pas decider d'afficher la rgponse dans une fenetre de dialogue ou 
sur la fenStre principale puisque cela a d^ja 6t6 ddfini au niveau du client 

[032] Un autre inconvenient que Ton peut soulever est qu'une seule fenetre peut Stre 

rafralchie k la fois« Par exemple, si la fenetre principale avait 6t6 divis^e en deux sous- 
fenStres, n est n^essaire a Tutilisateur d'adresser deux lequStes successives au serveur 
pour obtenir le ra£ta!bhissement successif des deux sous fengtres. Par aiUeurs, les mo- 
difications d'affichage se font uniquement par rafiiatchissement de rint6gralite d'une 
paitie de I'^cran alors qu'il est possible que la demande du client ne r^ponde qu'& une 
simple demande de mise ^ jour de ceitaines donn6es. Suivant le dispositif actuel, il est 
cependant n^cessaire de rafraichir rint^gralit6 de I'dcran pour n'importe quel type de 
modification demand6e. 

[033] n n'y a pas de moyen efiScace pour stocker des informations au niveau du poste 
client si ce n'est le recours h des « cookies » (t6moins) qui sont cependant de petite 
taille et qui n^cessite un transit par le i6seau h chaque requete, 

[034] Une fois que Tutilisateur a saisi sa requete celle-d est transmise par le biais du 
r6seau Internet avec le support de protocoles de communication du type http (Hyper 
Text Transfer Ptotocol). Cette 6tape est repr6sentfc au repere 1 aia figure 1. Le 
traitement de la requSte est op6r6 au niveau du serveur et est pr6sent6 au rep^ 2, Une 
r6pons6 est ensuite g6n6r66 comme pr^sent^e au repere 3, ici sous forme de page au 
format html qui implique la combinaison dans une mSme r^onse des 616nents de 
donn6es et des 61^ents de pr&entation de ce qui doit §tre affichS k Tutilisateur. A 
chaque fois que Ton souhaite accdder k une page, il faut ainsi t^Iecharger depuis la 
partie serveur Tintegralite de la page HTML contenant les donn^es h afficher (doimees 
variables et donnSes « statiques » de formatage - ex : textes d'aide, couleurs, polices 
de caractbres. . Ainsi le volume des pages transmises sur le r6seau s*avfcre important. 

[03S] Le repere 4 de la figure 1 montre que la r6ponse sous forme de page Web est 

adress^e au client, n faut noter que poiu: des applications prof essionnelles les donn^es 
doivent 6tre enciypt^ ce qui implique un temps de traitemrat et un cofit induit 
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d'autant plus important que le volume des donn6es k crypter est 61ev6. 
[036] Au niveau du poste client, Tutilisateur peut ensuite disposer de 1' affichage de la 
r6ponse comme pn&entS au point 5 en figure 1. Get affichage est r&lis^ par le biais 
d'une application de navigation telle que celle disponible sous la marque Internet 
Explorer (D. 

[037] Au niveau local, certaines actions peuvent alors avoir lieu pour 6viter de recourir 
systeraatiquement an serveur. Ainsi certaines ^plications par exeraple 6dit6es en Java 
Script peuvent §tre impl6ment^ au niveau du poste client pour produire certains 
outils. Un autre inconvenient des dispositifs actuels est done qu'il n^cessite de recourir 
k des outils additionnels k progranomer au langage Java Script au niveau du poste 
client 

[038] La figure 2 presente au contraire un exemple de scenario de fonctionnement d*un 
dispositif d'interfapage graphique selon Tinvention. 

[039] Comme indiqu6 prdc^lemment, rarchitecture actuelle utilis^e dans le cadre du 

r&eau Internet (World Wide Web) pose des problfemes dans la mesure oii Tint^gralitd 
de pages au fomiat HTML sont t616chargfes vars le poste client 

[040] Comme visible en figure 2, tel n'est pas le cas de la pr&ente invention. 

[041] Plus particulierement, lorsque TutiUsateur entie une requgte h destination de la 
partie s^veur, une demande sous forme d'un message contenant les informations 
saisies par F utilisateur est g6n&6e au format XML (E3rtensible N&rk-up Language) ou 
sous un autre format structur6. Dans la mesure oh la demande du client aiTisi g&i&^e 
reflate Taction de I'utilisateur, elle a 6t6 d€aomm6e « 6v6nemmt » i la r^ttence 1 de 
la figure 2. 

[042] Apr&s transmission, cette demande « 6v6nement » est regue et trait6e au niveau de 
la partie serveur. La premise pbase du traitem^t consiste en une analyse du contenu 
de la demande ce qui est fait au niveau d'une couche d'interface utilisateur du serveur 
qui sera presente plus en detail ci-apr6s. Ensuite, on procSde au traitement des donn^es 
de la demande « ev^nement » au niveau d'une couche d'application qui sera 6galement 
pr^ent^e plus loin. 

[043] Ces phases sont presentees au rep^re 2 « traitement » de la figure Z Une fois que la 
demande a 6i6 tcaitto, la paitie serveur g^n&re la r6ponse appropri6e h I'attration du 
client Dans ce cadre, au lieu de construire une page au format HTML compl&te, on 
genere selon Tinvention une suite d'instructions qui sera a interpreter par le client 
Cela donne en particulier une graude flexibilit6 en ce qui conceme le comportement du 
poste client Par exemple, un seul message peut permettrc d'op^rer des operations de 
raj&alchissement d'une partie de T&ran, d'ouvdr une bolte de dialogue, d'afficher une 
bone de message etc. . . et ce de fagon simultanfe. 

[044] Une fois cr^, le message est transmis sous fomie d'un document XML (Extensible 
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Mark-up Language) 6ventuellement aprte compression et oyptage en direction du 
poste client. Cette operation est representee au rep^re 4 par le tenne instruction qui 
correspond h la fonctionnalite decrite au paragraphe pr&edent 

[045] Ce message d'iustiuction est leju au niveau du poste climt et doit Stre interprete. 

[0461 Bn particulier, les donn^^ ^mamiques comprises dans la leponse du serveur sont 
r6cup6rees et pourront etre fusionn^es avec un module de visualisation qui correspond 
aux objets statiques n^cessaires a Tafifichage, Chaque modele de visualisation est par 
ailleurs cr64 au niveau du poste client, par association d' elements de construction. Ce 
sont les donates d'instractioii qui determinent les Elements de constraction h associer. 
La combinaison par fusion des deux types de donn6es (couche de presentation et 
donnees dynamiques issues du serveur) permet la citation de donn^es completes k 
afficher, en particulier sous forme d'une page au format HTML. On peut dans ce cadre 
utiliser pour la visualisation les fonctionnalit6s de moyens de navigation connus et 
standard, tels que le navigateur diffuse sous la marque Internet Explorer ®. 

[047] Les avantages de Toperation de fusion ainsi lealisee dans la partie client sont 

multiples. En premier lieu, une fois que les modules de visualisation et leurs eiemmts 
de dependance (images, scripts, etc... auxquels font appel les modeles) ont et6 
recuperes et sont disponibles au niveau du poste client, seules les donnees dynamiques 
sont k adresser par le biais du reseau de communication. On abaisse done fortement la 
consommatLon du reseau. 

[048] La mise h jour des donnees statiques est de plus tcte econome en ressources de 
transmission car il s'agit d'elements de petite dimension. Par exemple, si un objet 
. graphique est k changer, il n'est pas necessaire de charger tout le modhle de vi- 
sualisation qui Tutilise. 

[049] En outre, seul le canal de transmission des donnees a besoin d'etre securise dans les 
moyens de cammunication ce qui permet de limiter les capacites d'encryptage ne- 
cessaires lorsque Ton souhaite securiser les communications. 

[050] Une fois que la fusion est operee, son resultat peut 6tre affiche au niveau du poste 
client tel que presente a I'etape 5 de la figure 2. 

[051] Une interaction locale avec Tutilisateur est ensuite possible tel que presente au 
point 6 et met en oeuvre un moteur de regies apte k appliquer des i6gle§ logiques 
associees au modfele de visualisation exploite et disponible localement, tel que cela 
sera precise plus loin. EUe peut inclure differents fonctionnements. 

[052] En particulier, si les instructions transmises par le serveur correspondent k des 
contcdles (tels un bouton pour rafRchage d'une liste deroulante), les evfinements 
realiser peuvent etre geres par un code au format de langage Java Script associe au 
contcdle considere. 

[053] Si les evenements k op6i&c compoitent des interactions entie diff&ents contrdles 
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(par exemple si le champ A est reiiseiga6, le champ B devient alors obligatoiie) on 
peut op6rer de diffifirentes fa^ns. 
[054] Ainsi, si Tinteractioii est coinplexe mais larement utilisfe, elle peut 6tre g^ree au 
niveau du serveor et demaiid6e sous fonne d'une iequ8te fonnulee par le poste client 
au poste serveur. 

[055] Si I'interaction est simple et peut gtre facilement impKmentfe, elle est g6i6G au 

niveau du poste client par le moteur de regie local. 
[056] Enfin, si aucuue des 6ventualit6s pr&6dentes ne semble opportune, il est possible 
de n^aliser des courts 36ments de codage au format Java Script h lier a la page pour 
i6a]iser une fonctionnalit^ telle qu'actuellement connue dans le domaine des pages 
HTML utilis6es pour le World Wide Web. 
[057] On d^rit ci-apr&s plus pr^is^ment une structure possible du dispositif de 

rinvention. Ce dispositif compraud une partie serveur implfeient^ avec des moyens 
informatiques connus comprenant des moyens de traitenaent sous forme de processeur 
et des moyens de stockage sous forme de mSmoire du type RAM (Random Access 
Mranory) ou ROM (Read Only Memory). La partie serveur s'entend d'une seule entity 
de serveur infoimatique distant ou de plusieurs serveors connect^ entie eux par des 
moyens de transmission usuels. 
[058] Le dispositif comprend 6galement une partie impl6ment6e localement au niveau du 
poste client pouvant par exemple fitre r6alis6e par un otdinateur personnel du ^pe PC 
(Personal Computer), visible en figure 3. 
[059] La partie serveur et le poste client sont reli& pour la transmission de donn^ par le 
biais de moyens de conununication pouvant par exemple etre r6alis& par 
rintermgdiaire d'un r&eau (R) de large extension (WAN : Wide Area Network). 
[060] On a represents en figure 3 diff6rmts constituants du dispositif de Tinvention et 

leur relation afin de mettre en oeuvre le proc6d6 d'interfagage ici dSait 
[061] Par I'intenn^diaire du rdseau repr&ent6 R, la partie serveur transmet une reponse a 
la demande fonnulee ant^rieurement par 1' utilisateur, la reponse compienant des 
donnees d'instractions et des donn^es ^ afficher. 
[062] On poucca notamment utiliser le standard XML comme format de langage de 

balisage. La reponse est le^ue au niveau d'un gestionnaire d'instractions apte a in- 
teipr^ter les donnees d'instruction contenues dans la nSponse pour determiner les 
actions a mener. Dans le cas d'un affichage a realiser, Tintetpretation comprend la de- 
termination des 616ments de construction k utiliser pour la g6n6ration du modele de vi- 
sualisation. 

[063] Les r^sultats de Tinteipietation sont tcansmis iL un moteur d'association apte a 
r^uperer les donn&s statiques constituant les figments de construction caract6- 
dstiques du module de visualisation px6c6d&TamGat d^nnin& On a lepr^nt^ en 
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figure 3 diff6rents elements de construction utilises pour la cr^on du module de vi- 
sualisation. En particulier, le module de visualisation associe une interface de 
description d^rivant les composants de haut niveau du modMe de visualisation, une 
couche de presentation lassemblant les diffiSnents ^16ments et attiibuts lies k une pr6- 
sentation graphique et des regies logiques qui correspondent h la logique locale qui 
doit gtre appliqu6e au modfele de visualisation durant son traitement 
[064] A titre piefere, la couche de presentation peut dgpendre des profils d'utilisateur, 
mais rinteiface de description et les regies logiques demeurent identiques. Les 
61&nents de construction peuvent par consequent etre des donn^es totalement inde- 
pendantes et etce steick6s dans des fichiecs s6par& ou dans un mdme fichier scion les 
besoins. 

[065] D'autres ^I^ments sont par ailleurs avantageusement associds aux modules de vi- 
sualisation ainsi crees. En particulier, des donnees de ressources de langage sont 
associ^es. Ces donnees sont 6galement choisies parmi diff6rentes ressources 
disponibles localement en m^moire cache au niveau du poste client On peut ainsi 
fadlement adapter la page k ci6er k une langue pr&Idteminge. L'indication de la 
ressource de langage k utilise est ^galement pc^sente dans les donndes d'instructions 
regues dans lar^ponse. 

[066] On peut anssi associer au modele de visualisation un ou plusieuis filtres. Ces filties 
compl^tent la pecsonnalisation rendue possible par la pr&ente invention. En efifet, ils 
pemettent d'adapter Tinfonnation disponible h. I'^cian k des paiam^tres particuliers au 
client C'est un moyen particulidrement efticace de modifier les composants visuels de 
V6craa de fapon non programmatique, par exemple en ce qui conceme les contrdles 
utilisateur (ex : suppression de certains contr61es de 1' toan, modification du caiacteie 
obligatoire de certaixis champs de saide...) 

[067] Au final, Tassodation du modele de visualisation, du ou des filties, des ressources 
de langage et des donnees dynamiques regues dans la r6ponse du s^eur ponxiet de 
former une page. 

[068] Cette association est pr^ent^e plus particuli^ement k la figure 5. 

[069] En revenant k la figure 3, on a reprSsente que la fiision entce les donnees statiques 
ainsi associ6es et les donnees dynamiques contenues dans la r^ponse s'op^e au niveau 
d'un moyen de fusion. Par le biais de la fiision on peut par exemple, cifor des donndes 
au foraiat XML. 

[070] Les applications de navigation standards, en particulier Intemet Explorer ® , 
exploitent des pages au format HTML. On effectue done avant la transmission k 
Tapplication de navigation une transfoimation vers ce fomiat HTML par le biais de 
moyens de transformation. 

[071] Les dtapes dSxiuchant k la visualisation pour rutilisateur sont alors celles im- 
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plement6es conventiormellement avec les navigateurs existants. Cependant, pour 
pennettre ime interaction am^lior^e avec f 'utilisateur sans un reconrs syst6inatique k 
r activity de la parde serveur, le dispositif de rinvendon comporte ^galement un 
moteur de ingles apte i exploiter les i&gles contenues dans un magasin de donnees. De 
cette fagon, on peut g6rer des interactions simples entre le navigateur et rutilisateur. 
Par exemple, on peut determiner localement les donntes k pr6voir dans un menu 
deroulant suivant le profil du client et suivant la saisie piecedemment oper6e par 
rutilisateur. On 6vite ainsi un recours syst^matique k une interrogation du serveur 
apite une saisie du client 

[072] On a £galement repr^sent6 en figure 3 une possibilite de mise & jour ou d'ajout de 
domi6es dans le magasin de donn6es. En effet, it peut ^tre utile de ra&alchir ou 
d'augmenter les donn^ contenues localement dans le magasin de donn&s et servant 
au moteur de regies. Pour ce faire, on adresse depuis la partie serveur jusqu'au poste 
climt une reponse contenant des donnees d' instructions et des donn6es a exploiter, ici 
en vue de leur stockage et non en vue de V afGchage. 

[073] A Inception, Tinstniction de stockage est inteipr^t6e ce qui r&ulte en une acdon de 
stockage des donnees contenues dans la reponse dans le Tnaggsiii de donnees. Cette 
6tap6 est ^galement repr^ent^e en figure 3* 

[074] Par ailleurs, le poste cEent comporte avantageusement un 616ment de cache 

constituant un moym de stockage de donndes disponible au niveau local et rfnng lequel 
peut 8tre stock6e une plura£t6 de donnees compienant les di£f£rents ^l^ments de 
construction, n s'agit done de donndes statiques qui sont gdn&alement utilis^es pour 
des pages de type HTML. Tout type de m6moire peut dtre utilis6 pour une telle 
m6moire cache et en particulier une mSmoiie morte de type ROM (Read Only 
Memory). 

[075] Suivant une piemiSxe possibility, les donnto statiques sont installSs des le depart au 

niveau du poste client et utilises lorsqu'ils sont demandfe pour etre fusionnfe avec des 

donnees issues du serveur. Ainsi, le serveur n'a pas k transmettie les diffiStents 

616ments ou objets utilises pour Taffichage. 
[076] n peut egalement airiver que des &6m&at& n6cessaires k I'affichage mais non 

pr&ents initialement au niveau du poste client doivent Stie utilises. 
[077] Dans ce cadre, la presente invention pennet la cr&ition des Pigments de construction 

au niveau de la partie serveur et leur transmission une seule fois au poste client pour 

stockage dans le cache et r6utilisation ultfirieure. 
[078] On a repr6sent6 en figure 4 Tfitape de fusion op6r6e entre les donndes issues du 

serveur et les donnees issues du cache local apr^ leur association. 
[079] Dans ce cadre, tl est repr6sentd que la fusion s'ef;fectue dans la partie du poste client 

apids r&:eptioQ des donn^ dynamiques issues du s^eur dans les iostructions 
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constitutives de la r6ponse du serveur. Le gestionnaire d' instructions, k reception des 
donndes du serveur, appelle las 6I6nients du module de visualisation coxrespondant 
pr&ents dans le cache. On les associe et on opere la fusion pour la realisation par 
exeixq>le d'une page a transmettre anx moyens de visualisation. 

[080] Si un 61£ment de construction n^cessaire n'est pas present initialement dans le 

cache* Top&ation d&rite pr6c6demment concemant sa transmission depuis la partie 
serveur au poste client est r6alisee auparavant 

[081] Avantageusement, on exploite des donn^es au format XML pour la creation du 
module de visualisation et pour les donntes a afficher. Une traduction au format 
HTML pent Stre op€i€& apxhs la fusion par des moyens de transformation de fa^on k 
obtemr un r&ultat sous forme de page HTML directement ej^loitable par une ap- 
plication de navigation conventionnelle. 

[082] On notera que Fobjet de la pr^sente invention assure une grande souplesse dans le 
d6ve1oppement des interfaces utilisateur graphique tout en limitant les volumes des 
donndes transmises au tiavers des i6seaux. Par allleurs, le poste client leste une 
stracture 16gfere et facilement instaJlfe et la partie serveur conserve un rdle primordial 
dans le traitement des donndes et la gestion des 61€ments de visualisation. 
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[001] 



Reyendications 

ftoc^e pom- r interface gmphiqaeenteunutifc in- 
fonnatique dans lequel on effectue les actions suivantes : entrfe d'lme demande 
par I'utilisateur au niveau d'un poste client, transmission de la demaade vers nne 
paitie serveur en vue du traitement de la demaade et de la generation d'une 
r§ponse, reception de la rgponse au niveau du poste client, affichage du rfeultat 
de la iSponse pour TutilisatBur, caiact6is6 par le fait que le poste client legoit 
une r^onse comprenant des donn&s d^instmction et des donn6es k afficher ; au 
niveau du poste client, on execute les donn^es d'instruction pour la construction 
d'un modele de visualisation k exploiter ; au niveau du poste cHent, on cr& ledit 
module de visuaUsation par association d'dl6ments de constraction di^onibles 
localement, on fusionne les donn6es k afficher avec le modfele de visualisation en 
vue de I'affichage du rgsultat de la fusion. 
[002] Proc6d6 selon la revendication 1, caract6is6 par le fait que les 616mente de 

construction comprennent une interface de description des objets du modele de 
visualisation, une couche de presentation et des rfegles logiques a appliquer 
localement au module de visualisation. 

Proc6d6 selon la revendication 1 ou 2 dans lequel, caract6ris6 par le feit que au 
niveau du poste client, on associe au modMe de visualisation ci^ une ressouice 
de langage panni les ressources de langage disponibles localement ou tele- 
chargeables de la partie serveur. 

Ptoc&i& selon Tune quelconque des revendications 1 ou 3, caiact6ris6 par le fait 
que au niveau du poste cUent, on associe au modfele de visualisation des filtres de 
peisonnalisation d'affidiage pour modifier le rendu visuel du module de vi- 
sualisation. 

[005] Ptoc^ selon Tune quelconque des revendications 1^4, caract6ris6 par le fait 

que, les donnfes d'instruction comportent Tindication du type et des 616ments de 
construction caract6xistiques de module de visualisation k ci6er. 

[006] Proc6d6 selon 1' une quelconque des revendications 1 a 5, caract6ris6 par le fait 

qu'on met ^ jour les donnees disponibles localement au niveau du poste client 
par les etapes suivantes : on ggnfere, au niveau du serveur, un message de 
stockage comprenant des domiges d'instraction de stockage et les donndes k 
stocks, on transmet le message de stocky au poste client, au niveau du poste 
cKent, on inteiprete les donnees d'instruction pour ejc&utear le stockage et on 
stocke les donnas k stocker dans une m^moire locale. 
[007] Procddd selon I'une quelconque des revendications 1 k 6, caract6iis6 par le fait 

qu'on effectue Taffichage au niveau du poste client par une application de 



[003] 



[004] 
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navigation, 

[008] Plroced^ selon Tune quelconque des revendications 1 a 7, caract6ris6 par le fait 

qu'on utilise des demises k afficher et des elements de construction des modeles 
de visuaUsation au fonnat XML, on traduit le r6sultat de la fusion au format 
HTML m vue de rafSchage. 

[009] Dispositif d'inteifesagegrapMquemtceunutilisateuretunsystfeme in- 

fonnatique, conaprenant : des moyens d' entree d'une demande par Tutilisateur au 
niveau d'un poste client, des moyens de communication entte le poste client et 
unepaitie serveur, des moyens de traitement dans lapaitie SCTveur pour la 
g^&ation d'une r6ponse, des moyens d'alEchage du i^ultat de la i^nse au 
niveau du poste cUent, caract&is6 par le fait que, la i^nse de la partie serveur 
comprend des donn&s d'instraction et des donn&s k afficher ; il comporte, au 
niveau du poste client, un gestionnaire d'instructions apte k interpreter les 
donnges d'instroction pour la constraction d'un modele de visualisation k 
exploiter ; il conqjorte un moteur d'associadon au niveau du poste client apte k 
cr6CT ledit module de visualisation par association d*61dmMits de constraction ; il 
comporte des moyras de stockage des 6I6ments de construction au niveau du 
poste client ; il comporte, au niveau du poste client, des moyens pour fusiomier 
le modae de visualisation et les donn^es k afBchCT, en vue de Taffichage du 
r6sultat de la fusion. 

[010] Diq)ositif selon la revendication 9, caract6ris6 par le fait que, les €l6misats de 

construction comprennent une interface de description des objets du module de 
visualisation, une couche de presentation et des regies logiques k appliquer 
localement au modele de visualisation. 

[01 1] Dispositif selon la revendication 10, caiact6ris6 par le fait qu'il comporte un 

moteur de regies apte k appliquea: les regies logiques du module de visualisation. 

[012] Dispositif selon 1' une quelconque des revendications 9 i 1 1, caract&is6 par le 

fait qu'il comporte une application de navigation pour raffichage du r^sultat de 
la fusion au niveau du poste client 
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